Communication systems link together two communication devices so that the devices can send information to each other in a call or other communication event. Information may include voice, text, images or video.
Many communications systems are essentially operated by centralized servers that are provided by the communication system provider. A user may obtain services from the communication system by accessing one of these servers. Before providing the user with any services of the communications system, the servers may perform an authentication process to identify the user and then check that the user is authorized to use the requested services.
One possible authentication and authorization process is provided by the Kerberos protocol, which is a network protocol for enabling nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The Kerberos protocol makes use of a trusted third party, known as a key distribution centre (KDC), to issue “tickets” that prove the identity of a user. An example is shown in FIG. 1.
FIG. 1 illustrates a communication system shown generally at 101 that comprises a client 102, a service server (SS) 103 and a KDC 104. The KDC comprises two logically separate parts: an authentication server (AS) 105 and a ticket granting server (TGS) 106. The KDC also comprises a database 107. When client 102 wants to access a service via SS 103 it first authenticates itself to AS 105. The client authenticates itself by sending the AS its user identity and a secret key it has created by hashing its password. The AS first checks whether the client is known to it by checking the database for the client's user identity and password. Although the client does not transmit its password as part of its request message, the AS is able to nonetheless check the password by performing the same hashing function on the password stored in the database to replicate the client's secret key, which was transmitted as part of the request message. If the AS authenticates the client successfully, it returns a “ticket-granting ticket” to the client, which the client can use to obtain a “service-granting ticket” from TGS 106. The client can then pass the “service-granting ticket” to the SS 103 to obtain the required service. All tickets are time-stamped and may be valid only for a limited period of time.
Each authenticating stage of the Kerberos protocol includes two parts: a message that contains a key encrypted in such a way that it can be decrypted only by the party that the ticket is intended to authenticate; and a ticket that also contains the key but which is encrypted in such a way that it can only be decrypted by the party that is intended to perform the authentication. As an example, the AS sends two messages to an authorized client. The first message is a client/TGS session key. It is encrypted with the client's secret key so that only the client can decrypt it. The second message includes the “ticket-granting ticket”. This also includes the client/TGS session key, but the ticket has been encrypted using the secret key of the TGS so that only the TGS can decrypt this part of the message. When the client wants to request a “service-granting ticket” from the TGS, it forwards the “ticket-granting ticket” to the TGS together with an authenticator including the client's user id and a timestamp that has been encrypted using the client/TGS session key. The TGS cannot decrypt the authenticator immediately, because it does not have the client/TGS session key. However, the TGS can decrypt the “ticket-granting ticket” (since that was encrypted using its secret key). By decrypting the “ticket-granting ticket”, the TGS obtains the client/TGS session key, which it can then use to decrypt the authenticator.
The process is very similar for the “service-granting ticket” issued by the TGS. At each stage, a session key for authenticating a client is sent in encrypted form so that it can only be decrypted by the intended recipient of the message. This ensures that the session key is not intercepted and used by a rogue third party. The session key itself is also used to encrypt part of the message, so that the recipient knows that the party that generated the message was in possession of the session key and is thus entitled to access the requested services.
The Kerberos protocol therefore involves the issuance of tickets to authenticate a user and grant access to a particular service. As an example, the user may request a ticket from the ticket granting server to access an email system. A ticket is then granted that the user gives to the mail server that:
1. Identifies the user (authentication); and
2. Authorizes the user to utilize the service.
Some communication systems do not rely on centralized servers. One such system is a peer-to-peer communication system, in which a plurality of end users can be connected for communication purposes via a communications structure such as the internet. The communication structure of a peer-to-peer system may be formed by a large number of distributed nodes. The distributed nodes may not necessarily be owned or operated by the communications system provider. Instead, the nodes may also be clients running software that programs them to behave both as a client utilizing the system and as a node providing the communications system. The communication structure can thus be created by essentially “borrowing” a small amount of computing resources from millions of devices. A user can then access the peer-to-peer system via any one of those devices. In such systems, it is no longer necessary for the user to access a centralized server in order to gain access to the communications system as a whole.
The Kerberos authentication mechanism has also been implemented in a peer-to-peer communication system (see e.g. “A Peer Mutual Authentication Method using PKI on Super Peer based Peer-to-Peer Systems” by Oh et al). This mechanism uses peers to authenticate other peers, rather than the AS, which reduces the load of ticket authentication on the AS. In the first stage of authentication, a peer A requests authentication from the AS via a super peer. The request includes a digital signature formed by encrypting the user ID and time stamp with the user's private key. The AS creates a session key that only peer A will be able to decrypt and sends it to the super peer. The super peer then sends a connection granted message including the session key to peer A.
In the second stage of authentication, peer A wants to establish a direct connection with peer B. A virtual communication channel is first established between peer A and peer B. Peer B may then request a ticket for the communication from peer A. Peer A then sends a ticket request message to the super peer and the super peer forwards the request to the AS. The AS creates a ticket encrypted with the session key of peer B and also the session key of peer A. This ticket is sent back to the super peer, which forwards it to peer A. Peer A then decrypts the ticket using its session key and sends the decrypted ticket to peer B over the virtual connection. Peer B decrypts the ticket and checks whether the user ID of peer A is on its user permission list. If so, peer B creates a new ticket having a long lifetime and sends it to peer A. Peer A can then use that ticket to access the service of peer B for the duration of the ticket.
The Kerberos protocol, whether implemented in a centralized server system or a peer-to-peer system, is limited in that it only authorizes access to a service of an end-system. In other words, the tickets authorize a client to access the services of a server, without reference to what the client may use that service for, to the location of the server providing the service, or to what path the client may use to access the service. The clients of many peer-to-peer systems have limited resources available and the super-nodes face high demand by forming the overlay for network traffic. It is therefore useful to be able to prevent attacks that demand clients and/or super nodes service undesirable connections. Such attacks include, for example, the sending of spam. Spammers can exploit open relays that forward email from any client to any destination. In general, spamming through an open relay is lucrative for spammers, as the final recipient sees only the mail relay as the spamming source (see “Botnet Spam Campaigns can be Long-Lasting: Evidence, Implications, and Analysis” by Pathak et al).
“A Peer Mutual Authentication Method using PKI on Super Peer based Peer-to-Peer Systems” does describe a peer issuing a ticket that authorizes another peer to connect to it. This ticket does not authorize the peers to use one of the super peers because it assumes that the peers establish a direct connection between them. This is not a realistic model of connectivity within a super-peer based peer-to-peer system, which achieve connectivity by using the super-peers to relay the connections (at least initial setup) rather than establish a direct connection between clients from the start.